This invention relates to distributed computer systems, fault-tolerance, and security.
Replication and majority voting are the conventional methods for achieving fault-tolerance in distributed systems. The system consists of a set of redundant processors all working on the same task in parallel, then voting on the individual processors"" results to pick one as the correct answer. This technique was first proposed, in the context of electronic computing, by John von Neumann about 1945 and has been in use for some time.
Early examples of this technique used centralized voting. Each processor sent its vote to a central counter, which analyzed the votes and determined a majority. There are several problems with centralized voting. First, the central counter represents a single point of failure for the system; if it fails, so does the entire system. Second, the system cannot be readily reconfiguredxe2x80x94once it is set up for centralized voting, it is difficult to employ for other tasks.
For these reasons, another technique developed, distributed voting. In a distributed voting system, there is no central counter. The processors communicate among themselves to determine the majority vote. Thus there is no longer a single point of failure for the system. If one processor drops out, the others operate without it. Another attractive feature of distributed systems is dual-mode operation. When a task is critical, as in a space vehicle""s launch phase, the processors operate in fault-tolerant mode. When fault tolerance is not required, as in the space vehicle""s cruise phase, the processors cease to be redundant and execute in parallel different subtasks. Such a system has been used in the Space Shuttle""s primary computer system since the 1970s (cf. A. Spector, D. Gifford, The Space Shuttle Primary Computer System, 27 Communications of the ACM, No. 9 (September 1984)).
Prior-art protocols for distributed voting fall into two main types: two-phase commit and Byzantine. Several other protocols have recently been proposed for secure distributed voting. Each of the prior-art protocols has shortcomings that the present invention overcomes.
Software voting has had several embodiments in the development of fault-tolerant computing (see J. Wensley, SIFT: The Design and Analysis of a Fault-Tolerant Computer for Aircraft Control, 66 Proceedings of the IEEE (October 1978), 1240-1255; G. Farber, Taskspecific Implementation of Fault Tolerance In Process Automation Systems, M. Dal Cin and E. Dilger, ed., Self-Diagnosis and Fault Tolerance, Werkhefte Nr. 4 Attempto (Tubingen, 1981); and E. Ammann, et al., ATTEMPTO: A Fault-Tolerant Multiprocessor Working Station: Design and Concepts, IEEE Computer Society, Digest of Papers FTCS-13, p10-13, (1983)). More recently, distributed voting has been used for fault diagnosis in linear processor arrays (cf. V. Roda, T. Lin, The Distributed Voting Strategy for Fault Diagnosis and Reconfiguration of Linear Processor Arrays, 34 Microelectronics Reliability (No. 6, June 1994), 955-967) where, in the absence of a centralized voter, the array elements share error flags that stem from comparing outputs between connected elements.
Current schemes of distributed voting subscribe to a common protocol. Once voting is complete and a majority result determined, one processor is chosen to commit the majority result to user 4. Thus all are examples of a two-phase commit protocol (see J. Gray and A., Reuter, Transaction Processing: Concepts and Techniques (Morgan Kaufmann, 1993)). Voting is the first phase, in which all participants share results. A second phase, in which the committal is executed, follows. A distinguished process coordinates the committal. This type of protocol is prominent in the prior art.
A second class of protocols for distributed voting are the so-called xe2x80x98Byzantinexe2x80x99 protocols. The SIFT (Software Implemented Fault Tolerance) Program (circa 1975) (described in J. Goldberg, A History of Research in Fault-Tolerant Computing at SRI International, A. Avizienis, H. Kopetz, J. C. Laprie, ed., The Evolution of Fault-Tolerant Computing (Springer, Wien, Austria, 1987)) was the first attempt to support fine-grained flexibility in fault-tolerant operation that entailed decentralized voting. This program was also the seedbed for solutions to important problems in fault-tolerant distributed systems (see L. Lamport et al., The Byzantine Generals Problem, 4 ACM Transactions on Programming Languages and Systems (No. 3, July 1982)). Byzantine protocols were developed to tolerate voters that can fail in a totally arbitrary manner, such as sending conflicting results to two or more different sets of participating voters. The goal of these protocols is to achieve Byzantine agreementxe2x80x94all participants should have a globally consistent view of the system. Byzantine faults are the most malicious kind of processor faults that can occur, and they are therefore are the most difficult to tolerate.
While Byzantine protocols are more secure than two-phase commit protocols, they are also more complex. The theoretical requirements necessary to guarantee correct system behavior in this situation can be summarized as follows: to tolerate f Byzantine faults, it is necessary to have 3f+1 independent participating voters in the Byzantine fault-tolerant scheme, where the voters are connected by 2f+1 disjoint communication paths, and exchange information f+1 times to arrive at exact consensus (see id.). To tolerate a single fault, the system must consist of four processors, each having three independent communication paths, and require two exchanges of information. To tolerant as few as three faults requires a system with 10 processors, each having seven independent communication paths, and four exchanges of information.
Because of the complexity inherent in a Byzantine fault-tolerant system, which implies huge costs, few such systems have been implemented commercially. This type of protocol is therefore impractical for a commercially viable (i.e., economically feasible) distributed voting system.
Several protocols have been proposed to overcome the problems described above. For example, M. Castro and B. Liskov (Practical Byzantine Fault Tolerance, Proceedings of the 3rd Symposium on Operating System Design and Implementation (February 1999) offered an algorithm whose action can be simplified as follows:
A client sends a request to one of the voters.
The voter multi-casts the request to the other voters.
The voters execute the request and send a reply to the client.
The client waits for f+1 replies with the same result, where f is the number of faults to be tolerated; this result is the final one.
This algorithm is not subject to the same problem as the two-phase commit protocol, since every voter can commit a result. However, it does require substantial computation by the client, which must compare all the replies until f+1 have arrived with the same result. Thus this algorithm does not scale well.
Another protocol is described by M. Reiter (How to Securely Replicate Services, 16 ACM Transactions on Programming Languages and Systems, No. 3 (May 1994)). Reiter makes use of a (k,n)-threshold signature. Informally; such a protocol generates a public key, along with n shares of a corresponding private key, each of which can produce a partial result on a signed message m. Any k of these partial results can then be used to reconstruct the whole of m. In this particular protocol, n is the number of voters, and k is one more than the number of tolerated faults. Each voter signs its result with its particular share of the private key and broadcasts it to the other voters. The voters then sort through the broadcast messages for k partial results that agree with its own result and combine them into the whole message m, where m would be the signed final result. The voter then sends m to the client, which accepts the first valid m sent.
This protocol is not subject to the error inherent in the two-phase commit protocol (since the digital signature assures the client that f+1 voters agreed with the result; otherwise the result could not have been signed). This protocol is also not computationally expensive for the client. It shifts to the voters the computational burden required to sort through the votes looking for matches. However, the large number of messages that must be sent among the voters, plus the effort of digitally signing and validating these messages, adversely impact the performance of the protocol.
There exist other protocols, each with advantages and disadvantages (see M. Reiter, The Rampart Toolkit for Building High-Integrity Services, Theory and Practice in Distributed Systems, Lecture Notes in Computer Science 938, 99-110; D. Malkhi, M. Reiter, Byzantine Quorum Systems, Proceedings of the 29th ACM Symposium on Theory of Computing (May 1997); K. Kihlstrom et al., The Secure Ring Protocols for Securing Group Communication, 3 Proceedings of the 31st Hawaii International Conference on System Sciences (January 1998), 317-326; Y. Deswarte et al., Intrusion Tolerance in Distributed Computing Systems, Proceedings of the 1991 IEEE Symposium on Research in Security and Privacy (May 1991), 110-121.). All make the common assumption that underlies replicating a state-machinexe2x80x94two different voters, starting in the same state and following the same instructions, will inevitably arrive at the same result. This assumption may not hold; for example, it does not hold for the case of so-called inexact voting.
In inexact voting, two results do not have to be bit-wise identical to be considered equal, as long as they fall within a pre-defined range of tolerance. When data comes from sensors that interact with the real world, it is quite unlikely that two different sensors will collect exactly the same data, even if they are arbitrarily close to one another and sample the same phenomena. Therefore some analysis is necessary to determine if the data is effectively equal, even if not identical.
In such situations the above protocols will all encounter problems, because they require that the replicated voters"" data be identical. For example, the (k,n)-threshold algorithm above cannot be used for inexact votingxe2x80x94the partial results must be identical to be combined into a whole result for the client.
Though some of these algorithms could be modified to handle inexact voting, multiple inexact comparisons would give rise to prohibitive performance costs. For example, the algorithm in which all voters send their results to the client would force the client to make multiple inexact comparisons to determine the majority. Since inexact comparisons can be complex, this requirement places an unacceptable burden on the client.
While the main difficulty with the above types of protocols is their lack of security, another important consideration is performance. Any alternative protocol that improves security must have performance equivalent to two-phase commit.
Distributed voting for fault-tolerance has the drawback that to obtain a result through comparisons lowers the throughput of the fault-tolerant task. Time is also lost by the added communications required. Increasing fault tolerance by offloading the voting onto all of the processors, thus avoiding the use of a centralized counter, comes with a cost. Distributing the majority voting adversely impacts throughput in even a small multiprocessor (R. E. Harper, J. H. Lala, and J. J. Deyst, Fault Tolerant Parallel Processor Architecture Overview, Proceedings of the 18th Fault-Tolerant Computing Symposium (June, 1988), 252-257). In the case of the SIFT (Software Implemented Fault Tolerance) Program (circa 1975), the implementation of the voting in software consumed as much as 60% of the processor""s raw throughput (see D. L. Palumbo, R. W. Butler, A Performance Evaluation of the Software-Implemented Fault-Tolerance Computer, 9 AIAA Journal of Guidance, Control, and Dynamics, (No. 2, March-April 1986), 175-180). Execution of these software-intensive functions in the MAFT multiprocessor was estimated as two orders of magnitude too slow for a usable system (see C. J. Walter, R. M. Kieckhafer, A. M. Finn, MAFT: A Multicomputer Architecture for Fault-Tolerance in Real-Time Control Systems, Proceedings of the IEEE Real Time Systems Symposium (December 1985)). Therefore, a fault-tolerant protocol for software-based majority voting must be chosen to yield the best performance possible.
An earlier paper (K. Kwiat, Distributed Voting Among Voters of Equal Complexity, Proceedings of the ISSAT International Conference on Reliability and Quality in Design (August 1999)) proposed a possible solution to the shortcomings of the two-phase commit protocol; namely, that the committal phase should be monitored to ensure that the committed result agrees with the majority vote. The apparatus and method to monitor this final phase is the subject of the present invention.
An object of the present invention is to provide inexact voting in a potentially hostile distributed environment while maintaining security, fault-tolerance, and performance.
A further object of the present invention is to provide a system of fault-tolerant distributed voters working on a redundant task that yields a correct result even if some minority of the voters are faulty or actively hostile.
Still a further object of the present invention is to provide a system of fault-tolerant distributed voters, working on a redundant task that yields a correct result even if some minority of the voters are faulty or actively hostile, that allows for inexact voting.
Yet another object of the present invention is to provide a fault-tolerant distributed system that overcomes the drawbacks of the prior art.
Briefly stated, the present invention provides a method and apparatus which provides improved security in distributed-environment voting. At least three voting processors running a majority voting algorithm are connected to a local area network (LAN) and exchange their individually determined results of a process application. Each result from each of the at least three voting processors is committed to an interface module where it is checked, authenticated and buffered. The occurrence of multiple committed results are checked for. Likewise, committed results are authenticated so as to insure that any result committed is in fact from a friendly processor and not a hostile one. The allotted time for receiving and buffering committed results is constrained by a first timed interval within the interface module. The first timed interval may be reset several times. The allotted time for checking and comparing the committed results from each of the at least three processors is constrained by a second timed interval within each voting processor. Furthermore, the timed interval greatly enhances security because it allows for number of retries by the majority voting algorithm to correct a contrary vote of a hostile or faulty processor. A majority vote of those authenticated committed results is formed once all necessary iterations of both the first and second timed intervals are completed. A voting process with enhanced security results and yields a majority vote that is correct despite the introduction of errors associated with faulty or hostile processors.
According to an embodiment of the invention, a method for improving the security in distributed environment voting, comprises the steps of: initiating a majority voting algorithm within each of at least three voting processors; distributing a committed vote from one of the at least three voting processors, which has not previously committed a vote, to a local area network; passing the committed vote from said local area network to an interface module; buffering, within the interface module, the committed vote from a user; triggering the start of a first timed interval during which subsequent committed votes are received and authenticated; terminating the majority voting algorithm and passing a final result to a user upon lapse of the first timed interval; triggering the start of a second timed interval, upon receipt of a committed vote, within each of at least three voting processors during which each of the at least three voting processors is permitted to compare the committed vote with its own vote; detecting, within each of at least three voting processors, an agreement or a dissent with the committed vote; pausing only those of the at least three voting processors which agree with said committed vote; and either reinitiating the majority voting algorithm upon detection of a new majority dissent with the committed vote or allowing the first timed interval to lapse if no new majority dissent is detected, thereby terminating aid majority voting algorithm.
According to a feature of the invention, apparatus for improving the security in distributed environment voting, comprises: means for initiating a majority voting algorithm within each of at least three voting processors; means for distributing a committed vote from one of the at least three voting processors, which has not previously committed a vote, to a local area network; means for passing a committed vote from a local area network to an interface module; means for buffering, within the interface module, a committed vote from a user; means for triggering the start of a first timed interval during which subsequent committed votes are received and authenticated; means for terminating the majority voting algorithm and passing a final result to the user upon lapse of the first timed interval; means for triggering the start of a second timed interval within each of the at least three voting processors, upon receipt of a committed vote; where the means for triggering further comprising: means for comparing by each of the at least three voting processors of a committed vote to its own vote; means for detecting, within each of the at least three voting processors, an agreement or a dissent with the committed vote; means for pausing only those of the at least three voting processors which agree with the committed vote and either means for reinitiating the majority voting algorithm upon detection of a new majority dissent with the committed vote or means for allowing the first timed interval to lapse if no new majority dissent is detected, thereby terminating the majority voting algorithm.
According to another feature of the invention, apparatus for improving the security in distributed environment voting, comprises: a first device that initiates a majority voting algorithm within each of at least three voting processors; a second device that distributes a committed vote from one of the at least three voting processors, which has not previously committed a vote, to a local area network; a third device that passes the committed vote from the local area network to an interface module; a fourth device that buffers, within the interface module, the committed vote from a user; a fifth device that triggers the start of a first timed interval during which subsequent committed votes are received and authenticated; a sixth device that terminates the majority voting algorithm and passes a final result to the user upon lapse of the first timed interval; a seventh device that triggers the start of a second timed interval within each of the at least three voting processors, upon receipt of the committed vote; a seventh device further comprising: an eighth device that compares the committed vote to the vote of each of the at least three voting processors; a ninth device that detects, within each of the at least three voting processors, an agreement or a dissent with the committed vote; a tenth device that pauses only those of the at least three voting processors which agree with the committed vote; and either an eleventh device that reinitiates the majority voting algorithm upon detection of a new majority dissent with the committed vote or a twelfth device that allows the first timed interval to lapse if no new majority dissent is detected, thereby terminating the majority voting algorithm.
The above, and other objects, features and advantages of the present invention will become apparent from the following description read in conjunction with the accompanying drawings, in which like reference numerals designate the same elements.